Explicit- Value Analysis 
Based on CEGAR and Interpolation 



Dirk Beyer and Stefan Lowe 
University of Passau, Germany 




^ UNIVERSITAT 
Tii PASSAU 

Fakultdt fur Informatik und Mathematik 



Technical Report, Number MIP-1205 
Department of Computer Science and Mathematics 
University of Passau, Germany 
December 2012 



Explicit- Value Analysis 
Based on CEGAR and Interpolation 

Dirk Beyer and Stefan Lowe 
University of Passau, Germany 



Abstract — Abstraction, counterexample-guided refinement, 
and interpolation are techniques that are essential to the success 
of predicate-based program analysis. These techniques have 
not yet been applied together to explicit-value program anal- 
ysis. We present an approach that integrates abstraction and 
interpolation-based refinement into an explicit-value analysis, i.e., 
a program analysis that tracks explicit values for a specified 
set of variables (the precision). The algorithm uses an abstract 
reachability graph as central data structure and a path-sensitive 
dynamic approach for precision adjustment. We evaluate our 
algorithm on the benchmark set of the Competition on Software 
Verification 2012 (SV-COMP'12) to show that our new approach 
is highly competitive. In addition, we show that combining 
our new approach with an auxiliary predicate analysis scores 
significantly higher than the SV-COMP'12 winner. 

I. Introduction 

Abstraction is one of the most important techniques to suc- 
cessfully verify industrial-scale program code, because the 
abstract model omits details about the concrete semantics 
of the program that are not necessary to prove or disprove 
the program's correctness. Counterexample-guided abstraction 
refinement (CEGAR) 1 14| is a technique that iteratively refines 
an abstract model using counterexamples. A counterexample 
is a witness of a property violation. In software verification, 
the counterexamples are error paths, i.e., paths through the 
program that violate the property. CEGAR starts with the 
most abstract model and checks if an error path can be 
found. If the analysis of the abstract model does not find 
an error path, then the analysis terminates, reporting that 
no violation exists. If the analysis finds an error path, the 
path is checked for feasibility, i.e., if the path is executable 
according to the concrete program semantics. If the error path 
is feasible, the analysis terminates, reporting the violation of 
the property, together with the feasible error path as witness. 
If the error path is infeasible, the violation is due to a too 
coarse abstract model and the infeasible error path is used to 
automatically refine the current abstraction. Then the analysis 
proceeds. Several successful tool implementations for software 
verification are based on abstraction and CEGAR (cf. |4|, 
@' 1121' US' ©' GD^- ^""^ig interpolation is a technique 
from logics that yields for two contradicting formulas an 
interpolant that contains less information than the first formula, 
but still enough to contradict the second formula p7| . In 
software verification, interpolation can be used to extract in- 
formation from infeasible error paths |21 1, where the resulting 
interpolants are used to refine the abstract model. Predicate 
abstraction is a successful abstraction technique for software 



model checking p8) , because its symbolic state representation 
blends well with strongest post-conditions, and abstractions 
can be computed efficiently with solvers for satisfiability 
modulo theories (SMT) CEGAR and lazy refinement (22) 
together with interpolation pT| effectively refine abstract 
models in the predicate domain. The recent competition on 
software verification (SV-COMP'12 |5^|, Table 3) shows that 
these advancements had a strong impact on the success of 
participating tools (cf. ||6|, ||T0), ||25), ||26)). 

Despite the success of abstraction, CEGAR, and interpola- 
tion in the field of predicate analysis, these techniques have 
not yet been combined and applied together to explicit-value 
analysis. We integrate these three techniques into an explicit- 
value analysis, a rather unsophisticated analysis that tracks for 
each program variable its current value explicitly (like constant 
propagation yj, but without join). First, we have to define the 
notion of abstraction for the explicit-value domain, and the 
precision of the analysis (i.e., the level of abstraction) by a set 
of program variables that the analysis has to track. Second, in 
order to automatically determine the necessary precision (i.e., 
a small set of program variables that need to be tracked) we use 
CEGAR iterations to discover finer precisions from infeasible 
error paths. Third, we define interpolation for the explicit- 
value domain and use this idea to construct an algorithm 
that efficiently extracts such a parsimonious precision that is 
sufficient to eliminate infeasible error paths. 

Example. Consider the simple example program in Fig. [T] 
This program contains a while loop in which a system call 
occurs. The loop exits if either the system call returns or 
a previously specified number of iterations x was performed. 
Because the body of the function system_call is unknown, the 
value of result is unknown. Also, the assumption [ticks > x] 
cannot be evaluated to true, because x is unknown. This 
program is correct, i.e., the error location in line 10 is not 
reachable. However, a simple explicit-value model checker that 
always tracks every variable would unroll the loop, always 
discovering new states, as the expression ticks = ticks + 1 
repeatedly assigns new values to variable ticks. Thus, due 
to extreme resource consumptions, the analysis would not 
terminate within practical time and memory limits, and is 
bound to give up on proving the safety property, eventually. 

The new approach for explicit-value analysis that we pro- 
pose can efficiently prove this program safe, because it tracks 
only those variables that are necessary to refute the infeasible 
error paths. In the first CEGAR iteration, the precision of 
the analysis is empty, i.e., no variable is tracked. Thus, the 



1 extern int system_call () ; 

2 int main ( int x ) { 

3 int flag , ticks , result ; 

4 flag = 0; ticks = 0; 

5 while (1) { 

6 ticks = ticks + 1 ; 

7 result = system_call () ; 

8 if(result==0||ticks>x){ brealc ; } 

9 } 

10 if (flag > 0) { ERROR: return 1; } 
11} 

Fig. 1: Example program to illustrate the effectiveness of CEGAR- 
based explicit-value analysis 



error location will be reached. Now, using our interpolation- 
inspired method to discover precisions from counterexample 
paths, the algorithm identifies that the variable flag (more 
precisely, the constraint flag — 0) has to be tracked. The 
analysis is re-started after this refinement. Because ticks is not 
in the precision (the variable is not tracked), the assignment 
ticks = ticks + 1 will not add new abstract states. Since 
no new successors are computed, the analysis stops unrolling 
the loop. The assume operation [flag > 0] is evaluated to 
false, and thus, the error label is not reachable. The analysis 
terminates, proving the program correct. 

In summary, the crucial effect of this approach is that 
only relevant variables are tracked in the analysis, while 
unimportant information is ignored. This greatly reduces the 
number of abstract states to be visited. 
Contributions. We make the following contributions: 

• We integrate the concepts of abstraction, CEGAR, and 
lazy abstraction refinement into explicit-value analysis. 

• Inspired by Craig interpolation for predicate analysis, we 
define a novel interpolation-like approach for discovering 
relevant variables for the explicit-value domain. This 
refinement algorithm is completely self-contained, i.e., 
independent from external libraries such as SMT solvers. 

• To further improve the effectiveness and efficiency of 
the analysis, we design a combination with a predicate 
analysis based on dynamic precision adjustment |9|. 

• We provide an open-source implementation of all our 
concepts and give evidence of the significant improve- 
ments by evaluating several approaches on benchmark 
verification tasks (C programs) from SV-COMP'12. 

Related Work. The explicit-state model checker Spin |23| 
can verify models of programs written in a language called 
Promela. For the verification of C programs, tools like 
MODExQ can extract Promela models from C source code. 
This process requires to give a specification of the abstraction 
level (user-defined extraction rules), i.e., the information of 
what should be included in the Promela model. Spin does not 
provide lazy-refinement-based CEGAR. Java Pathfinder |20| 
is an explicit-state model checker for Java programs. There has 
been work p4| on integrating CEGAR into Java Pathfinder, 
using an approach different from interpolation. 

Program analysis with dynamic precision adjustment Q 
is an approach to adjust the precision of combined analyses 



on-the-fly, i.e., during the analysis run; the precision of one 
analysis can be increased based on a current situation in 
another analysis. For example, if an explicit-value analysis 
stores too many different values for a variable, then the 
dynamic precision adjustment can remove that variable from 
the precision of the explicit-value analysis and add a predicate 
about that variable to the precision of a predicate analysis. 
This means that the tracking of the variable is "moved" from 
the explicit domain to the symbolic domain. One configuration 



that we present later in this paper uses this approach (cf. III-F i 



' littp://cm.beU- labs .com/cm/cs/what/modex/ 



The tool Dagger | |T9) improves the verification of C pro- 
grams by applying interpolation-based refinement to octagon 
and polyhedra domains. To avoid imprecision due to widening 
in the join-based data-flow analysis. Dagger replaces the 
standard widen operator by a so called interpolated-widen 
operator, which increases the precision of the data-flow anal- 
ysis and thus avoids false alarms. The algorithm Vinta f2^ 
applies interpolation-based refinement to interval-like abstract 
domains. If the state exploration finds an error path, then 
Vinta performs a feasibility check using bounded model 
checking (BMC), and if the error path is infeasible, it computes 
interpolants. The interpolants are used to refine the invariants 
that the abstract domain operates on. Vinta requires an SMT 
solver for feasibility checks and interpolation. 

More tools are mentioned in our evaluation section, where 
we compare (in terms of precision and efficiency) our tool 
implementation with tools that participated in S V-COMP' 12. 

There is, to the best of our knowledge, no work that inte- 
grates abstraction, CEGAR, lazy refinement, and interpolation 
into explicit-state model checking. We make those techniques 
available for the explicit-value domain. 

II. Preliminaries 

Our approach is based on several existing concepts, and in this 
section we remind the reader of some basic definitions. 

A. Programs, Control-Flow Automata, States 

We restrict the presentation to a simple imperative program- 
ming language, where all operations are either assignments 
or assume operations, and all variables range over integersn 
The following definitions are taken from previous work fTW: 
A program is represented by a control-flow automaton CFA. 
A CFA A = {L, G) consists of a set L of program locations, 
which model the program counter, and a set G C L x Ops x L 
of control-flow edges, which model the operations that are 
executed when control flows from one program location to 
another. The set of program variables that occur in oper- 
ations from Ops is denoted by X. A verification prob- 
lem P = (A, Zo,4) consists of a CFA A, representing the 
program, an initial program location /q G L, representing the 
program entry, and a target program location 4 e L, which 
represents the error. 

A concrete data state of a program is a variable assignment 
cd : X ^ Ij, which assigns to each program variable an 

'Our implementation is based on CPACHECKER, which operates on 
C programs; non-recursive function calls ai'e supported. 
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integer value. A concrete state of a program is a pair (Z, erf), 
where / <E L is a program location and cd is a concrete data 
state. The set of all concrete states of a program is denoted 
by C, a subset r C C is called region. Each edge g G G defines 
a labeled transition relation A C C x {g} x C. The complete 
transition relation is the union over all control-flow edges: 

= UgeG write cAc' if (c, 5, c') e and c^-c' if 

there exists a g with cAc'. 

An abstract data state represents a region of concrete 
data states, formally defined as abstract variable assign- 
ment. An abstract variable assignment is a partial func- 
tion V : X — e-j> Z U {T, _L}, which maps variables in the def- 
inition range of function v to integer values or T or _L. 
The special value T is used to represent an unknown 
value, e.g., resulting from an uninitialized variable or an 
external function call, and the special value _L is used 
to represent no value, i.e., a contradicting variable assign- 
ment. We denote the definition range for a partial func- 
tion / as def(/) — {x \3y : {x, y) e /}, and the restric- 
tion of a partial function / to a new definition range Y 
as f\Y = / n (F X (Z U {T, _L})). An abstract vai'iable 
assignment v represents the region |w] of all concrete 
data states cd for which v is valid, formally: {vj = 
{cd I Vx e def(i;) : cd{x) — v{x) or v{x) — T}. An abstract 
state of a program is a pair {I, v), representing the following 
set of concrete states: {{l,cd) \ cd E Iv}}. 



B. Configurable Program Analysis with 
Dynamic Precision Adjustment 

We use the framework of configurable program analysis 
(CPA) m, extended by the concept of dynamic precision 
adjustment f9l. Such a CPA supports adjusting the precision 
of an analysis during the exploration of the program's ab- 
stract state space. A composite CPA can control the precision 
of its component analyses during the verification process, 
i.e., it can make a component analysis more abstract, and 
thus more efficient, or it can make a component analy 
sis more precise, and thus more expensive. A CPA D = 
(D, n, merge, stop, prec) consists of (1) an abstract do- 
main D, (2) a set 11 of precisions, (3) a transfer relation 
(4) a merge operator merge, (5) a termination check stop, 
and (6) a precision adjustment function prec. Based on these 
components and operators, we can formulate a flexible and 
customizable reachability algorithm, which is adapted from 
previous work IS), p2). 



in previous work the composition is done automatically 
by the framework implementation CPAchecker. 

The CPA for explicit-value analysis, which tracks integer 
values for the variables of a program explicitly, is defined as 
C = {Die, He, ~^C: rnergej-, stopj-, prec^) and consists of the 
following components |9|: 

1. The abstract domain Dc = (C, V, |-]) contains the set 
C of concrete data states, and uses the semi-lattice V = 
(y, T,_L, !Z,U), which consists of the set V ^ {X Z) 
of abstract variable assignments, where Z = Z U {Tz,-Lz} 
induces the flat lattice over the integer values (we write Z to 
denote the set of integer values). The top element T E V, with 
T(x) = Tz for all x £ X, is the abstract variable assignment 
that holds no specific value for any variable, and the bottom 
element _L e F, with -L{x) = J-z for all x € X, is the 
abstract variable assignment which models that there is no 
value assignment possible, i.e., a state that cannot be reached 
in an execution of the program. The partial order Q C V x V 
is defined as v C v' if for all x E X, we have v{x) = v'{x) 
or v{x) — ±z or v'{x) — Tz- The join U : V x V ^ V 
yields the least upper bound for two variable assignments. The 
concretization function |-| ; 1/ — 2*^ assigns to each abstract 
data state v its meaning, i.e., the set of concrete data states 
that it represents. 

2. The set of precisions He = 2^ is the set of subsets of 
program variables. A precision tt e He specifies a set of 
variables to be tracked. For example, tt = means that no 
variable is tracked, and tt = X means that every program 
variable is tracked. 

3. The transfer relation has the transfer v-^{v',tt) if 
(1) g — (■, assume(p), •) and for all x G X : 

±z if (y, J-z) & V for some y £ X 

or the formula p/y is unsatisfiable 
c if c is the only satisfying assignment of 

the formula p for variable x 
Tz otherwise 

where p/y denotes the interpretation of a predicate p over 
variables from X for an abstract variable assignment v, that 



C. Explicit- Value Analysis as CPA 

In the following, we define a component CPA that tracks 
expUcit integer values for program variables. In order to 
obtain a complete analysis, we construct a composite CPA 
that consists of the component CPA for explicit values and 
another component CPA for tracking the program locations 
(CPA for location analysis, as previously described |9|). For 
the composite CPA, the general definitions of the abstract 
domain, the transfer relation, and the other operators are given 
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where exp/y denotes the interpretation of an expression exp 
over variables from X for an abstract value assignment v: 
J-z if {y, Tz) G V for some y E X 
Tz if {y, Tz) £v or y <^ def(w) 

for some y E X that occurs in exp 
exp/y — { c otherwise, where expression exp 
evaluates to c after replacing each 
occurrence of variable x with x E def(u) 
by v(x) in exp 

4. The merge operator does not combine elements when 
control flow meets: merge^{v , v' , tt) — v' . 
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5. The termination check considers abstract states individually: 

stopc(w, R, tt) = {3v' £ R:vQ v'). 

6. The precision adjustment function computes a new abstract 
state with precision based on the abstract state v and the 
precision tt by restricting the variable assignment v to those 
variables that appear in tt, formally: prec(v, tt, i?) — {y\Tj,n). 
(In this analysis instance, prec only adjusts the abstract state 
according to the current precision tt, and leaves the precision 
itself unchanged.) 

The precision of the analysis controls which program vari- 
ables are tracked in an abstract state. In other approaches, 
this information is hard-wired in either the abstract-domain 
elements or the algorithm itself. The concept of CPA supports 
different precisions for different abstract states. A simple 
analysis can start with an initial precision and propagate it 
to new abstract states, such that the overall analysis uses a 
globally uniform precision. It is also possible to specify a 
precision individually per program location, instead of using 
one global precision. Our refinement approach in the next 
section will be based on location-specific precisions. 

D. Predicate Analysis as CPA 

The abstract domain of predicates p8) was successfully used 
in several tools for software model checking (e.g., Q, Q, 
pO) , IT3) , | [T6| , p5]). In a predicate analysis, the precision is 
defined as a set of predicates, and the abstract states track the 
strongest set of predicates that are fulfilled (cartesian predicate 
abstraction) or the strongest boolean combination of predicates 
that are fulfilled (boolean predicate abstraction). This means, 
the abstraction level of the abstract model is determined by 
predicates that are tracked in the analysis. Predicate analysis 
is also implemented as a CPA in the framework CPAchecker, 
and a detailed description is available yjj. The precision 
is freely adjustable also in the predicate analysis, and we 
use this feature later in this article to compose a combined 
analysis. This analysis uses the predicate analysis to track 
variables that have many distinct values — a scenario in which 
the explicit-value analysis alone would be inefficient. The 
combined analysis adjusts the overall precision by removing 
variables with many distinct values from the precision of 
the explicit-value analysis and adds predicates about these 
variables to the precision of the predicate analysis ||9J to allow 
the combined analysis to run efficiently. 

E. Lazy Abstraction 

The concept of lazy abstraction 1*221 consists of two ideas: 
First, the abstract reachability graph (ARG) — the unfolding of 
the control-flow graph, representing our central data structure 
to store abstract states — is constructed on-the-fly, i.e., only 
when needed and only for parts of the state space that are 
reachable. We implement this using the standard reachability 
algorithm for CPAs as described in the next subsection. 
Second, the abstract states in the ARG are refined only where 
necessary along infeasible error paths in order to eliminate 
those paths. This is implemented by using CPAs with dynamic 



Algorithm 1 CPA(D,i?o, W^o), adapted from ||9) 



Input: a CPA D = {D, IT, merge, stop, prec), 

a set Ro (1 (E X IT) of abstract states with precision, 
a subset Wo C _Ro of frontier abstract states with precision, 
where E denotes the set of elements of the semi-lattice of D 
Output: a set of reachable abstract states with precision, 
a subset of frontier abstract states with precision 
Variables: two sets reached and waitlist of elements of iJ x 11 
reached := Rq; waitlist := Wq; 
while waitlist / do 

choose (e, tt) from waitlist; remove (e, tt) from waitlist; 
for each e' with e~^{e',n) do 
// Precision adjustment, 
(e, tt) :— prec(e', TT, reached); 
if isTargetState(e) then 

return (reached U (e, n), waitlist); 
for each (e ', tt") £ reached do 

// Combine with existing abstract state. 
Gnew ■■= merge(e,e",7r); 
if enem / e" then 

waitlist — (waitlist U {(e„e„, tt)}) \ {(e", tt")}; 
reached :— (reached U {(e„e„, tt)}) \ {(e", tt")}; 
// Add new abstract state? 
if ^ stop(e, {e I (e,-) G reached}, tt) then 
waitlist := waitlist U {(e, tt)}; 
reached := reached U {(e,7r)} 
return (reached, 0); 



precision adjustment, where the refinement procedure oper- 
ates on location-specific precisions and where the precision- 
adjustment operator always removes unnecessary information 
from abstract states, as outlined above. 



F. Reachability Algorithm for CPA 

Algorithm [T] keeps updating two sets of abstract states with 
precision: the set reached to store all abstract states with pre- 
cision that are found to be reachable, and a set waitlist to store 
all abstract states with precision that are not yet processed, i.e., 
the frontier. The state exploration starts with choosing and 
removing an abstract state with precision from the waitlist, 
and the algorithm considers each abstract successor according 
to the transfer relation. Next, for the successor, the algorithm 
adjusts the precision of the successor using the precision 
adjustment function prec. If the successor is a target state 
(i.e., a violation of the property is found), then the algorithm 
terminates, returning the current sets reached and waitlist 
— possibly as input for a subsequent precision refinement, 
as shown below (cf Alg. |2]). Otherwise, using the given 
operator merge, the abstract successor state is combined with 
each existing abstract state from reached. If the operator merge 
has added information to the new abstract state, such that the 
old abstract state is subsumed, then the old abstract state with 
precision is replaced by the new abstract state with precision 
in the sets reached and waitlist. If after the merge step the 
resulting new abstract state with precision is covered by the 
set reached, then further exploration of this abstract state is 
stopped. Otherwise, the abstract state with its precision is 
added to the set reached and to the set waitlist. Finally, once 
the set waitlist is empty, the set reached is returned. 
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G. Counterexample-Guided Abstraction Refinement 

Counterexample-guided abstraction refinement (CEGAR) f\A\ 
is a technique for automatic stepwise refinement of an abstract 
model. CEGAR is based on three concepts: (1) a precision, 
which determines the current level of abstraction, (2) a fea- 
sibility check, deciding if an abstract error path is feasible, 
i.e., if there exists a corresponding concrete error path, and 
(3) a refinement procedure, which takes as input an infeasible 
error path and extracts a precision that suffices to instruct 
the exploration algorithm to not explore the same path again 
later Algorithm |2] shows an outline of a generic and simple 
CEGAR algorithm. The algorithm starts checking a program 
using a coarse initial precision ttq. It uses the reachability 
algorithm Alg. [T] for computing the reachable abstract state 
space, returning the sets reached and waitlist. If the analysis 
has exhaustively checked all program states and did not reach 
the error, indicated by an empty set waitlist, then the algorithm 
terminates and reports that the program is safe. If the algorithm 
finds an error in the abstract state space, i.e., a counterexample 
for the given specification, then the exploration algorithm 
stops and returns the unfinished, incomplete sets reached and 
waitlist. Now the according abstract error path is extracted 
from the set reached using procedure extractErrorPath and 
analyzed for feasibility using the procedure isFeasible for 
feasibility check. If the abstract error path is feasible, meaning 
there exists a corresponding concrete error path, then this 
error path represents a violation of the specification and the 
algorithm terminates, reporting a bug. If the error path is 
infeasible, i.e., not corresponding to a concrete program path, 
then the precision was too coarse and needs to be refined. 
The algorithm extracts certain information from the error path 
in order to refine the precision based on that information 
using the procedure Refine for refinement, which returns a 
precision tt that makes the analysis strong enough to refute 
the infeasible error path in further state-space explorations. 
The current precision is extended using the precision returned 
by the refinement procedure and the analysis is restarted with 
this refined precision. Instead of restarting from the initial sets 
for reached and waitlist, we can also prune those parts of the 
ARG that need to be rediscovered with new precisions, and 
replace the precision of the leaf nodes in the ARG with the 
refined precision, and then restart the exploration on the pruned 
sets. Our contribution in the next section is to introduce new 
implementations for the feasibility check as well as for the 
refinement procedure. 



H. Interpolation 

For a pair of formulas if~ and (p+ such that A (p"*" is 
unsatisfiable, a Craig interpolant V' is a formula that fulfills 
the following requirements p7) : 

1) the implication ip^ ^ holds, 

2) the conjunction ijj A (/s^ is unsatisfiable, and 

3) V' only contains symbols that occur in both ip^ and Lp^ . 

Such a Craig interpolant is guaranteed to exist for many useful 
theories, for example, the theory of linear arithmetic with 



Algorithm 2 GEGAR(D, eo, ttq) 



Input: a configurable program analysis with dynamic precision 
adjustment D = {D, IT, merge, stop, prec), 
an initial abstract state eo G E with precision ttq G 11, 
where E denotes the set of elements of the semi-lattice of D 
Output: verification result safe or unsafe 
Variables: a set reached of elements of _E x 11, 
a set waitlist of elements of iJ x H, 
an error path a = {(opj, Zi), (op„, L)) 
reached := {(eo, ttq)}; waitlist := {(eo, tto)}; t!" := 7I"o; 
while true do 

(reached, waitlist) ~ CPA(D, reached, waitlist); 
if waitlist = then 

return safe 
else 

a :— extractErrorPath(reached); 

if isFeasible((7) then // error path is feasible: report bug 

return unsafe 
else // error path is not feasible: refine and restart 

TT := TT U Refine((T); 

reached := (eo,7r); waitlist :— (eo,7r); 

uninterpreted functions, as implemented in some SMT solvers 
(e.g., MathSAi[5 SMTInterpoiQi. 

CEGAR based on Craig interpolation has been proven 
successful in the predicate domain. Therefore, we investigate if 
this technique is also beneficial for explicit-value model check- 
ing. Interpolants from the predicate domain, which consist of 
path formulas, are not useful for the explicit domain. Hence, 
we need to develop a procedure to compute interpolants for the 
explicit domain, which we introduce in the following section. 

III. Refinement-Based ExpUcit- Value Analysis 

The level of abstraction in our explicit-value analysis is deter- 
mined by the precisions for abstract variable assignments over 
program variables. The CEGAR-based iterative refinement 
needs an extraction method to obtain the necessary precision 
from infeasible eiTor paths. We use our novel notion of 
interpolation for the explicit domain to achieve this goal. 

A. Explicit- Value Abstraction 

We now introduce some necessary operations on abstract vari- 
able assignments, the semantics of operations and paths, and 
the precision for abstract variable assignments and programs, 
in order to be able to concisely discuss interpolation for 
abstract variable assignments and constraint sequences. 

The operations implication and conjunction for abstract 
variable assignments are defined as follows: implication for 
V and v': v ^ v' if def(i;') C def(-y) and for each variable 
X £ def(u) n def(i;') we have v{x) = v'{x) or v{x) = _L 
or v'{x) = T; conjunction for v and v': for each variable 
X E def(u) U def(w') we have 



{vAv'){x) 



v{x) if x €z def(v) and x ^ def(u') 

v'{x) if X ^ def(i;) and x G def(u') 

v{x) if v{x) — v'{x) 

_L if T ^^^(x) ^^'(a;) 

T otherwise {v{x) = T or v'{x) — T) 



- http://mathsat4.disi.unitn.it 




' http://ultimate.infonnatik.uni-freiburg.de/smtinterpol 
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Furthermore we define contradiction for an abstract variable 
assignment v. v is contradicting if there is a variable x E 
def(u) such that v{x) = _L (which implies = 0); and 
renaming for v: the abstract variable assignment u^'^^, with 
y ^ def(u), results from v by renaming variable x to y: 
v-^y = iv\{{x,vix))})U {(y.vix))}. 

The semantics of an operation op G Ops is defined 
by the strongest post-operator SP op{-) for abstract variable 
assignments: given an abstract variable assignment v, SPop(w) 
represents the set of data states that are reachable from 
any of the states in the region represented by v after the 
execution of op. Formally, given an abstract variable assign- 
ment V and an assignment operation s exp, we have 



^Ps:=expiv) = Vlx\{s}^Vs.^exp with V^-.^exp = { (s, exp/.^ ) }, 

where exp^y denotes the interpretation of expression exp for 
the abstract variable assignment v (cf. definition of exp/y in 
Subsection |II-C| l. That is, the value of variable s is the result 
of the arithmetic evaluation of expression exp, or T if not 
all values in the expression are known, or _L if no value is 
possible (an abstract data state in which a variable is assigned 
to _L does not represent any concrete data state). Given an 
abstract variable assignment v and an assume operation [p], 
we have SP[p](t;) = v' and for all x €1 X we have v'{x) ~ _L 
if {y, J-) G V for some variable x G X or the formula p/,„ is 
unsatisfiable, or v'{x) = c if c is the only satisfying assignment 
of the formula p/„ for variable x, or v'{x) = T in all other 



cases; the formula p/„ is defined as in Subsection II-C 

A path (T is a sequence {{opi, li), {op^^, In)} of pairs 
of an operation and a location. The path cr is called pro- 
gram path if for every i with 1 < i < n there exists 
a CFA edge g — (4_i,opj,4) and Iq is the initial pro- 
gram location, i.e., a represents a syntactic walk through 
the CFA. Every path a = {{opi, li), (op.^, In)) defines a 
constraint sequence 7^ ~ {opi, opn) ■ The semantics of 
a program path a = {{op-^^,li), ...,{opjj^,ln)) is defined as 
the successive application of the strongest post-operator to 
each operation of the corresponding constraint sequence 7^: 
SP^„(w) = SPop„(...SPop^(..SPop^(w). .)...). The set of con- 
crete program states that result from running a is represented 
by the pair {In, SP.y^ {vq)), where wq = {} is the initial abstract 
variable assignment that does not map any variable to a value. 
A program path a is feasible if SP^^ (va) is not contradicting, 
i.e., SP~f^{vo){x) ^ _L for all variables x in def(SP^^ (wo)). A 
concrete state {ln,cdn) is reachable from a region r, denoted 
by {ln,cdn) S Reach{r), if there exists a feasible program 
path (T = ((opi, /i), (op„, /„)) with {lo,vo) e r and 
cdn G |SP^^ (wo)!- A location I is reachable if there exists 
a concrete state c such that (/, c) is reachable. A program is 
SAFE if le is not reachable. 

The precision for an abstract variable assignment is a set n 
of variables. The explicit-value abstraction for an abstract 
variable assignment is an abstract variable assignment that 
is defined only on variables that are in the precision tt. 
For example, the explicit-value abstraction for the variable 
assignment u = {x i-> 2, y 1— 5} and the precision tt = {x} 
is the abstract variable assignment w'^ = {x 1— >■ 2}. 

The precision for a program is a function 11 : L — !■ 2'''", 
which assigns to each program location a precision for an 



abstract variable assignment, i.e., a set of variables for which 
the analysis is instructed to track values. A lazy explicit-value 
abstraction of a program uses different precisions for different 
abstract states on different program paths in the abstract 
reachability graph (ARG). The explicit-value abstraction for 
a variable assignment at location / is computed using the 
precision Il{l). 

B. CEGAR for Explicit- Value Model Checking 

We now instantiate the three components of the CEGAR 
technique, i.e., precision, feasibility check, and refinement, for 
our explicit-value analysis. The precisions that our CEGAR 
instance uses are the above introduced precisions for a program 
(which assign to each program location a set of variables), and 
we start the CEGAR iteration with the empty precision, i.e., 
^init{l) = for each I E L, such that no variable will be 
tracked. 

The feasibility check for a path a is performed by exe- 
cuting an explicit-value analysis of the path a using the full 
precision Il{l) = X for all locations I, i.e., all variables 
will be tracked. This is equivalent to computing SP^^(t;o) 
and check if the result is contradicting, i.e., if there is a 
variable for which the resulting abstract variable assignment 
is _L. This feasibility check is extremely efficient, because the 
path is finite and the strongest post-operations for abstract 
variable assignments are simple arithmetic evaluations. If the 
feasibility check reaches the error location 4, then this error 
can be reported. If the check cannot reach the error location, 
because of a contradicting abstract variable assignment, then a 
refinement is necessary because at least one constraint depends 
on a variable that was not yet tracked. 

We define the last component of the CEGAR technique, the 
refinement, after we introduced the notion of interpolation for 
variable assignments and constraint sequences. 

C. Interpolation for Variable Assignments 

For each infeasible error path in the above mentioned re- 
finement operation, we need to determine a precision that 
assigns to each program location on that path the set of 
program variables that the explicit-value analysis needs to 
track in order to eliminate that infeasible error path in future 
explorations. Therefore, we define an interpolant for abstract 
variable assignments. 

An interpolant for a pair of abstract variable assignments 
and w+, such that A w+ is contradicting, is an abstract 
variable assignment V that fulfills the following requirements: 

1) the implication ^ V holds, 

2) the conjunction V Av~^ is contradicting, and 

3) V only contains variables in its definition range which 
are in the definition ranges of both and w+ (def(V) C 
def(w~) ndef(t;+)). 

Lemma. For a given pair {v~, w+) of abstract variable 
assignments, such that v~ A u+ is contradicting, an interpolant 
exists. Such an interpolant can be computed in time 0{m+n), 
where m and n are the sizes of and u+, respectively. 
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Algorithm 3 lnterpolate(7 ,7^) 



Algorithm 4 Ref\ne{a) 



Input: two constraint sequences 7^ and 7+, 

with 7~ A 7^ is contradicting 
Output: a constraint sequence F, 

whiicli is an interpolant for 7" and 7^ 
Variables: an abstract variable assignment v 
v~SP^-{0) 
for each x € def(u) do 

if SP^+{v|dcf(„)y{j;}) is contradicting then 

// X is not relevant and should not occur in the interpolant 

V ■— W|dcf(i>)\{i} 

// construct the interpolating constraint sequence 

r:= 

for each x G def(«) do 

// construct an assume constraint for x 

r := r A {[a; = v{x)]) 
return F 

Proof. The variable assignment W|jgf(^+) is an interpolant for 
the pair {v~, 

Note. The above-mentioned interpolant that simply results 
from restricting v~ to the definition range of t)+ (common 
definition range) is of course not a 'good' interpolant. In 
practice, we strive for interpolants with minimal definition 
range, and use slightly more expensive algorithms to compute 
them. Interpolation for abstract variable assignments is a 
first idea to approach the problem, but since we need to 
extract interpolants for paths, we next define interpolation for 
constraint sequences. 

D. Interpolation for Constraint Sequences 

A more expressive interpolation can be achieved by 
considering constraint sequences. The conjunction 7 A 7' 
of two constraint sequences 7 = (opj^, op„) and 
7' = {op'i, op'„i) is defined as their concatenation, 
i.e., 7 A 7' = {opi, op„, opi, op'„-^), the implication of 
7 and 7' (denoted by 7 7') as SP^(wo) ^ SP^'(wo). and 
7 is contradicting if |SP-y(z;o)] = 0, with vq — {}■ 

An interpolant for a pair of constraint sequences 7^ and 7+, 
such that 7^ A 7+ is contradicting, is a constraint sequence 
r that fulfills the following requirements: 

1) the implication 7" =J> F holds, 

2) the conjunction F A 7+ is contradicting, and 

3) F contains in its constraints only variables that occur in 
the constraints of both 7" and 7+. 

Lemma. For a given pair (7^, 7+) of constraint sequences, 
such that 7" A 7+ is contradicting, an interpolant exists. Such 
an interpolant is computable in time 0{m ■ n), where m and 
n are the sizes of 7^ and 7+, respectively. 

Proof. Algorithm Interpolate (Alg. |3]l returns an interpolant 
for two constraint sequences 7" and 7+. The algorithm 
starts with computing the strongest post-condition for 7^ 
and assigns the result to the abstract variable assignment v, 
which then may contain up to m variables. Per definition, the 
strongest post-condition for 7+ of variable assignment v is 
contradicting. Next we try to eliminate each variable from v, 
by testing if removing it from v makes the strongest post- 
condition for 7+ of V contradicting (each such test takes 



Input: infeasible error patii a — {(op^, Zi), (op„, l„)) 
Output: precision IT 

Variables: interpolating constraint sequence F 

r:=(); 

n(/) ~ 0, for all program locations /; 
for j 1 to n — 1 do 

7"^ := {op^+l,■■■,op„) 

II inductive interpolation 

F := lnterpolate(F A opj,7+) 

// extract variables from variable assignment that results from F 
n{k) ■- {x\{x,z) GSPr(0) and_L/z/T} 
return FT 



n SP steps). If it is contradicting, the variable can be removed. 
If not, the variable is necessary to prove the contradiction 
of the two constraint sequences, and thus, should occur in 
the interpolant. Note that this keeps only variables in v that 
occur in 7+ as well. The rest of the algorithm constructs a 
constraint sequence from the variable assignment, in order to 
return an interpolating constraint sequence, which fulfills the 
three requirements of an interpolant. A naive implementation 
can compute such an interpolant in 0{{m + n)^). 

E. Refinement Based on Explicit-Interpolation 

The goal of our interpolation-based refinement for explicit- 
value analysis is to determine a localized precision that is 
strong enough to eliminate an infeasible error path in future 
explorations. This criterion is fulfilled by the property of 
interpolants. A second goal is to have a precision that is as 
weak as possible, by creating interpolants that have a definition 
range as small as possible, in order to be parsimonious in 
tracking variables and creating abstract states. 

We apply the idea of interpolation for constraint sequences 
to assemble a precision-extraction algorithm: Algorithm Refine 
(Alg.|4]i takes as input an infeasible program path, and returns 
a precision for a program. A further requirement is that 
the procedure computes inductive interpolants Q, i.e., each 
interpolant along the path contains just enough information 
to prove the remaining path infeasible. This is needed in 
order to ensure that the interpolants at the different locations 
achieve the goal of providing a precision that eliminates 
the infeasible error path from further explorations. For every 
program location k along an infeasible error path a, starting 
at we split the constraint sequence of the path into a 
constraint prefix 7^, which consists of the constraints from 
the start location Iq to /j, and a constraint suffix 7+, which 
consists of the path from the location k to 4- For computing 
inductive interpolants, we replace the constraint prefix by the 
conjunction of the last interpolant and the current constraint. 
The precision is extracted by computing the abstract vari- 
able assignment for the interpolating constraint sequence and 
assigning the relevant variables as precision for the current 
location k, i.e., the set of all variables that are necessary to 
be tracked in order to eliminate the error path from future 
exploration of the state space. This algorithm for precision 
extraction yields a parsimonious precision, i.e., a precision 
containing just enough information to exclude the infeasible 
error path, and can be directly plugged-in as refinement routine 
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Fig. 2: Illustration of one refinement iteration; from left to right: a simple example CFA, an infeasible error path with the abstract states 
annotated in the nodes (precision was empty, nothing is tracked), the interpolated variable assignments annotated in the nodes, the precisions 
extracted from the interpolants annotated in the nodes, and finally the CFA with the abstract states annotated in the nodes according to the 
new precision (unreached nodes — including error — shown in gray) 



of the CEGAR algorithm (cf. Alg. |2|. Note that the repetitive 
interpolations are not an efficiency bottleneck. The path is 
always finite, without any loops or branching, and thus, even 
a full-precision check can be decided efficiently. Figure |2] 
illustrates the interpolation process on a simple example. 

F. Optimizations 

In our implementation, we added several optimizations to 
improve the performance of our approach. 
ARG Pruning instead of Restart. Our refinement rou- 
tine Refine (cf. Alg. |4]i returns a set of variables (precision) 
that are important for deciding the reachability of the error 
location. One of the ideas of lazy abstraction refinement p2) 
is that the precision is only refined where necessary, i.e., only 
at the locations along the path that was considered in the 
refinement; the other parts of the state space are not refined. 
As mentioned in the discussion of the CEGAR algorithm (cf. 
Alg. |2|i, it is not necessary to restart the exploration of the 
state space from scratch after a refinement. Instead, we identify 
the descendant closest to the root of the abstract reachability 
graph (ARG) in which the precision was refined, and the re- 
exploration of the state space continues from there. In total, 
this significantly reduces the number of tracked variables per 
abstract state, which in turn leads to a more efficient analysis, 
because it drastically increases the chance that a new abstract 
state is covered by an existing abstract state. 
Scoped Precision Refinement. The precision for a program 
assigns to each program location the set of variables that 
need to be tracked at that location, and the interpolation- 
based refinement adds new variables precisely at the locations 
for which they were discovered during refinement. In our 
experience, the number of refinements is reduced significantly 
if we add a variable to the precision not only at the particular 
location for which it was discovered, but at all locations in 



the local scope of the variable. This helps to avoid adding a 
variable twice that can occur on two different branches. By 
adding the variable to the precision "in advance" in the local 
scope, we abbreviate some refinement iterations. For example, 
consider Fig. |2] again. After the illustrated refinement, another 
refinement step would be necessary, in order to discover that 
variable a needs to be tracked at location N4 as well (to prevent 
the analysis from going through location N6). By adding 
variable a to the precision of all locations in the scope of 
variable a immediately after the first refinement, the program 
can be proved safe without further refinement. This effect 
was also observed, and used, in the software model checker 
Blast |6|. 

Precise Counterexample Check. In order to further increase 
the precision of our analysis, we double-check all feasible er- 
ror paths using bit-precise bounded model checking (BMC)|5 
by generating a path program ||7| for the error path and let the 
BMC confirm the bug. Since the generated path program does 
not contain any loop or branching, it can be verified efficiently. 
If both our analysis and the bit-precise BMC report unsafe, 
then we report a bug. If the BMC cannot confirm the bug, 
our analysis continues trying to find another error path. This 
additional feature is available as a command-line option in our 
implementation. 

AuxiUary Predicate Analysis. As an additional option for 
further improvement of the analysis, we implemented the 
combination with a predicate analysis, as outlined in existing 
work |9|. In this combination, if the explicit-value analysis 
finds an error path, this path is first checked for satisfiability in 
the predicate domain. If the satisfiability check is positive, the 
result unsafe can be reported and the error path is returned; 
if negative, then the explicit-value domain is not expressive 
enough to analyze that program path (e.g., due to inequalities). 

''In our implementation, we use CBMC jl5j as bounded model checker. 
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In this case, we ask the predicate analysis to refine its 
abstraction along that path, which yields a refined predicate 
precision that eliminates the error path but considering the 
facts along that path in the (more precise, and more expensive) 
predicate domain. We need to parsimoniously use this feature 
because the post-operations of the predicate analysis are much 
more expensive than the post-operations of the explicit-value 
analysis. In general, after a refinement step, either the explicit- 
value precision is refined (preferred) or the predicate precision 
is refined (only if explicit does not succeed). 

Using the concept of dynamic precision adjustment f9], we 
also switch off the tracking of variables in the explicit-value 
domain if the number of different values on a path exceeds a 
certain threshold. After this, the predicate analysis will get 
switched on (by the above-mentioned mechanism) and the 
facts on that path are further tracked using predicates. This is 
important if the explicit-value analysis tries to unwind loops; 
the symbolic, predicate-based analysis can often store a large 
number of values more efficiently. 

Note that this refinement-based, parallel composition with 
precision adjustment of the explicit-value analysis and the 
predicate analysis is more powerful than a mere parallel 
product of the two analyses, because after each refinement, the 
explicit part of the analysis tracks exactly what it is capable of 
tracking, while the auxiliary predicate analysis takes care of 
only those facts that are beyond the capabilities of the explicit 
domain, resulting in a lightweight analysis on both ends. Such 
a combination is easy to achieve in our implementation, be- 
cause we use the framework of configurable program analysis 
(CPA), which lets the user freely configure such combinations. 

IV. Experiments 

In order to demonstrate that our approach yields a significant 
practical improvement of verification efficiency and effec- 
tiveness, we implemented our algorithms and compared our 
new techniques to existing tools for software verification. In 
the following, we show that the application of abstraction, 
CEGAR, and interpolation to the explicit-value domain con- 
siderably improves the number of solved instances and the run 
time. Combinations of the new explicit-value analysis with 
a predicate-based analysis can further increase the number 
of solved instances. All our experiments were performed on 
hardware identical to that of the SV-COMP'12 |5|, such that 
our results are comparable to all the results obtained there. 
Compared Verification Approaclies. For presentation, we re- 
strict the comparison of our new approach to the SV-COMP' 12 
participants Blast, SATabs, and the competition winner cpa- 
MEMO, all of which are based on predicate abstraction and 
CEGAR. Furthermore, to investigate performance differences 
in the same tool environment, we also compare with different 
configurations of CPAchecker. The model checker Blast is 
based on predicate abstraction, and uses a CEGAR loop for 
abstraction refinement. The predicates for the precision are 
learned from counterexample paths using interpolation. The 
central data structure of the algorithm is an ARG, which 
is lazily constructed and refined. Blast won the category 
"DeviceDrivers64" in the SV-COMP'12, and got bronze in 



another category. The model checker SATabs is also based on 
predicate abstraction and CEGAR, but in contrast to Blast, it 
constructs and checks in every iteration of the CEGAR loop a 
new boolean program based on the current precision of the 
predicate abstraction, and does not use lazy abstraction or 
interpolation. SATabs got silver in the categories "SystemC" 
and "Concurrency", and bronze in another category. The 
model checker cpa-memo is based on predicate abstraction, 
CEGAR, and interpolation, but extends it with the concepts of 
adjustable-block encoding pT) and block-abstraction memo- 
ization |26|. cpa-memo won the category "Overall", got silver 
in two more categories, and bronze in another category. 

We implemented our concepts as extensions of 
CPAchecker |10|, a software- verification framework 
based on configurable program analysis (CPA). We compare 
with the existing explicit-value analysis (without abstraction, 
CEGAR, and interpolation) and with the existing predicate 
analysis that is based on boolean predicate abstraction, 
CEGAR, interpolation, and adjustable-block encoding fTT) . 
We used the trunk version of CPAcHECKEF^in revision 6615. 

Verification Tasks. For the evaluation of our approach, 
we use all SV-COMP' 12|!] verification tasks that do 
not involve concurrency properties (all categories ex- 
cept category "Concurrency"). All obtained experimental 
data as well as the tool implementation are available at 
http : / /www .sosy-lab.org/ ■-^dbeyer /cpa- explicit| 
Quality Measures. We compare the verification results of 
all verification approaches based on three measures for ver- 
ification quality: First, we take the run time, in seconds, of 
the verification runs to measure the efficiency of an approach. 
Obviously, the lower the run time, the better the tool. Second, 
we use the number of correctly solved instances of verification 
tasks to measure the effectiveness of an approach. The more 
instances a tool can solve, the more powerful the analysis is. 
Third, and most importantly, we use the scoring schema of the 
SV-COMP' 12 as indicator for the quality of an approach. The 
scoring schema implements a community-agreed weighting 
schema, namely, that it is more difficult to prove a program 
correct compared to finding a bug and that a wrong answer 
should be penalized with double the scores that a correct 
answer would have achieved. For a full discussion of the 
official rules and benchmarks of the SV-COMP' 12, we refer to 
the competition report |5 1. Besides the data tables, we use plots 
of quantile functions |5| for visualizing the number of solved 
instances and the verification time. The quantile function for 
one approach contains all pairs {x, y) such that the maximum 
run time of the x fastest results is y. We use a logarithmic 
scale for the time range from 1 s to 1000 s and a linear scale 
for the time range between s and 1 s. In addition, we decorate 
the graphs with symbols at every fifth data point in order to 
make the graphs distinguishable on gray-scale prints. 

Improvements of Explicit- Value Analysis. In the first evalu- 
ation, we compare two different configurations of the explicit- 
value analysis: cpa-expl refers to the existing implementation 
of a standard explicit-value analysis without abstraction and 



' http://cpachecker.sosv-lab.org 



http://sv-comp.sosy-lab.org/2012 
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TABLE I: Comparison with purely explicit, non-CEGAR approach 
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Fig. 3: Quantile plot: purely explicit analyses 

refinement, and cPA-EXPLiip refers to the new approach, which 
implements abstraction, CEGAR, and interpolation. Table |l] 
and Fig. |3] show that the new approach uses less time, solves 
more instances, and obtains more points in the SV-COMP'12 
scoring schema. 

Improvements of Combination with Predicate Analysis. 

In the second evaluation, we compare the refinement-based 
explicit analysis against a standard predicate analysis, as well 
as to the predicate analysis combined with cpa-expl and cpa- 
EXPLiip, respectively: cpa-pred refers to a standard predicate 
analysis that CPAchecker offers (ABE-lf, [llj), CPA-EXPLitp 
refers again to the expUcit-value analysis, which implements 
abstraction, CEGAR, and interpolation, cpa-expl-pred refers 
to the combination of predicate analysis and explicit-value 
analysis without refinement, and cpa-expliip-pred refers to the 
combination of predicate analysis and explicit-value analysis 
with refinement. 

Table [n] and Fig. |4] show that the new combination approach 
outperforms the existing approaches cpa-pred and cPA-EXPLiip 
in terms of solved instances and score. The comparison with 
column CPA-EXPL-PRED is interesting because it shows that the 
combination of two analyses is an improvement even without 
refinement in the explicit-value analysis, but switching on 
the refinement in both domains makes the new combination 
significantly more effective. 

Comparison with State-of-the-Art Verifiers. In the third 
evaluation, we compare our new combination approach with 
three established tools: Blast refers to the standard Blast 
configuration that participated in the SV-COMP'12, SATabs 
also refers to the respective standard configuration, cpa-memo 
refers to a special predicate abstraction that is based on block- 
abstraction memoization, and cpa-expliip-pred refers to our 
novel approach, which combines a predicate analysis (cpa- 
pred) with the new explicit-value analysis that is based on 
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abstraction, CEGAR, and interpolation (cPA-EXPLiip). Table III 
and Fig. |5] show that the new approach outperforms Blast 
and SATabs by consuming considerably less verification time, 
more solved instances, and a better score. Even compared 
to the SV-COMP'12 winner, cpa-memo, our new approach 
scores higher. It is interesting to observe that the difference in 
scores is much higher than the difference in solved instances: 
this means cpa-memo had many incorrect verification results, 
which in turn shows that oiu" new combination is significantly 
more precise. 

V. Conclusion 

The surprising insight of this work is that it is possible 
to achieve — without using sophisticated SMT-solvers during 
the abstraction refinement — a performance and precision 
that can compete with the world's leading symbolic model 
checkers, which are based on SMT-based predicate abstraction. 
We achieved this by incorporating the ideas of abstraction. 
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5.8 


6 


5 


11 


8 


6 


12 


SystemC 


22 


17 


1900 


34 


26 


1500 


62 


45 


1500 


61 


44 


3700 


Overall 


237 


163 


7100 


244 


164 


2500 


280 


192 


5300 


318 


211 


5600 


TABLE II: Comparison with predicate-based configurations 


Categoiy 




BLAST 






SATABS 




CPA-MEMO 


CPA- 


■EXPLiip- 


■PRED 




score 


solved 


time 


score 


solved 


time 


score 


solved 


time 


score 


solved 


time 


ControlFlowInt 


71 


51 


9900 


75 


47 


5400 


140 


91 


3200 


141 


91 


830 


DeviceDrivers 


72 


51 


30 


71 


43 


140 


51 


46 


93 


71 


46 


87 


DeviceDrivers64 


55 


33 


1400 


32 


17 


3200 


49 


33 


500 


37 


24 


980 


HeaplVIanipul 














4 


9 


16 


8 


6 


12 


SystemC 


33 


23 


4000 


57 


40 


5000 


36 


30 


450 


61 


44 


3700 


Overall 


231 


158 


15000 


235 


147 


14000 


280 


209 


4300 


318 


211 


5600 



TABLE III: Comparison with three existing tools 



counterexample-guided abstraction refinement, lazy abstrac- 
tion refinement, and interpolation into a standard, simple 
explicit-value analysis. 

We further improved the performance and precision by 
combining our refinement-based explicit-value analysis with 
a predicate analysis, in order to benefit from the comple- 
mentary advantages of the methods. The combination analysis 
dynamically adjusts the precision Q for an optimal trade- 
off between the precision of the explicit analysis and the 
precision of the auxiliary predicate analysis. This combination 
out-performs state-of-the-art model checkers, witnessed by a 
thorough comparison on a standardized set of benchmarks. 

Despite the overall success of our new approach, individual 
instances of benchmarks show different performance with 
different configurations — i.e., either with or without CEGAR. 
Therefore, a general heuristic for finding a suitable strategy for 
a single verification task would be beneficial. Also, we envi- 
sion better support for pointers and data structures, because 
our interpolation approach can be efficiently applied even 
with high precision. Moreover, we so far only combined our 
interpolation approach with an auxiliary predicate analysis in 
the ABE-lf configuration, and we have not yet tried to combine 
this with the superior block-abstraction memoization (ABM) 
| [26) technique. Finally, we plan to extend our interpolation 
approach to other abstract domains like intervals. 
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